1. Field of the Invention
The present invention relates to a method utilized in a mobile communication environment, and more particularly, to a method of handling delayed triggering when a target mobile device or user equipment (UE) is temporarily unreachable in the mobile communication environment.
2. Description of the Prior Art
Machine-type communication (MTC) is one type of data communication including one or more entities not requiring human interactions. That is, the MTC refers to the concept of communication based on a network such as the existing GERAN, UMTS, long-term evolution (LTE), or the like used by a machine device instead of a mobile station (MS) used by a user. The machine device used in the MTC can be called an MTC device. There are various MTC devices such as a vending machine, a machine of measuring a water level at a dam, etc. That is, the MTC is widely applicable in various fields. The MTC device has features different from that of a typical MS. Therefore, a service optimized to the MTC may differ from a service optimized to human-to-human communication. In comparison with a current mobile network communication service, the MTC can be characterized as a different market scenario, data communication, less costs and efforts, a potentially great number of MSs for communication, wide service areas, low traffic per MS, etc.
Machine-to-machine (M2M) communications may take advantage of deployed wireless networks based on Third Generation Partnership Project (3GPP) technologies such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-Advanced), and/or other technologies such as WiMAX (Worldwide Interoperability for Microwave Access) or those developed by the Institute for Institute of Electrical and Electronics Engineers (IEEE) and 3GPP2. M2M communications may use networks based on these technologies to deliver business solutions in a cost-effective manner. In a circumstance involving ubiquitous deployment of wireless networks, the availability of the wireless networks may facilitate and/or encourage the deployment and use of M2M devices. Additionally, further enhancements to these technologies may provide additional opportunities for the deployment of M2M-based solutions.
A Device Trigger Delivery Gateway (DT-GW) could be a standalone physical entity or a functional entity. At least one Device Trigger Delivery Gateway is owned by and deployed in a HPLMN that supports the MTC device trigger feature for subscribed devices. The DT-GW is deployed on the boundary between the HPLMN and the public Internet. Alternatively, the DT-GW is owned and operated by a 3rd party on behalf of the HPLMN and/or deployed in the public Internet. In which case, a secure tunnelling mechanism between the DT-GW and the HPLMN is utilized.
The MTC server sends a trigger request message encapsulated in an IP packet to the appropriate DT-GW or interworking function for machine type communication (MTC-IWF). The trigger request message could contain pertinent information needed to route the trigger (e.g. device subscriber identity, trigger command/arguments, relevant device location information, security parameters, etc.). When a trigger request message is received from a submitting node (e.g. an authorized MTC server), the DT-GW or MTC-IWF should first authorize the received trigger request message; making sure it originated from a trusted MTC server and is targeted for a device for which the MTC server is authorized to trigger. The next step is for the DT-GW or MTC-IWF to determine the reachability of the MTC device. Per the requirements specified in clause 5.8 of 3GPP documentation TS 22.368 b.1.1, a trigger-able MTC device can be received in the detached state, in the attached state without a publically routable PDP context/PDN connection and in the attached state with a publically routable PDP context/PDN connection.
When the MTC server sends Device trigger request to MTC-IWF (or DT-GW), the MTC-IWF can retrieve info about registered network control node of the target triggering UE from the home subscriber server/home location register (HSS/HLR). Then the MTC-IWF forwards the Device trigger request to one of the registered network control node, e.g. MSC/SGSN/MME. If the forwarding network control node cannot deliver the trigger request to the target UE (e.g. the UE is temporarily unreachable), it replies delivery failure report to the MTC-IWF. However when the UE becomes reachable to a network control node later, it is not clear how the MTC-IWF delivers the trigger request to the UE via a network control node which may be different from the one which failed to deliver the trigger request.
The MTC-IWF can quarry a domain name server (DNS) or PDN gateway (P-GW) about the IP address of the target UE and send the trigger request via the obtained IP address in the user plane. If the user plane delivery fails, the MTC-IWF can only try to deliver trigger via T5 or T4 path in the control plane. It is not clear how the MTC-IWF delivers the trigger via the user plane if the IP address of the UE becomes reachable.